Micro-payments via Eecient Coin-flipping Extended Abstract

We present an authenticated coinipping protocol and its proof of security. We demonstrate the applicability of our scheme for online randomized micro-payment protocols. We also review some essential aspects of other micro-payment proposals (including SET, PayWord and MicroMint, PayTree, NetCheque, NetCash, Agora, NetCard, CAFE, Pederson's proposal, micro-iKP, Milicent, proposal of Jarecki-Odlyzko, proposal of Yacobi, SVP, DigiCash, Rivest's \Lottery tickets as MicroCash" and Wheeler's proposal) and compare it with our scheme. 1 Design Principles and Parameters This paper presents another micro-payment scheme, designed for world-wide web applications. It avoids many shortcomings of previous schemes. In particular, our scheme can support tiny transactions (like buying individual web-pages) at (amortized) cost of a fraction of a cent per web-page. We give an overview of other existing proposals and compare it with our scheme. In the heart of our construction is a new, on-line, fair and authenticated coinipping protocol, which is of independent interest and could be used in other settings as well. We start by surveying the setting and parameters considered. The Participants: As in all the payment schemes, the main participants are the User U who wishes to get some information (i.e., a web page) from some Vendor V (i.e. from some web site, like on-line Encyclopedia Britannica). Vendor V wants to get paid for the provided information, while the User U wishes to pay only for the information that she gets. We operate in the setting where neither Vendors nor Users trust each other, hence, Vendors wish to make sure that they get paid for the provided information, while Users wish to make sure that they are not \over-charged" for the services that they did not get. Additionally, there is the third party, a Broker (or a Bank) B which assists in various ways for fund transfer between users and vendors and tries to detect/prevent various fraud of dishonest Users and Vendors. In the simplest setting, the Broker (or a Bank) is assumed to be trusted. More generally, some schemes do not assume that Brokers/Banks are trusted, and then introduce one or two more additional participants, such as central authority and/or one or several arbiters in order to resolve disputes and provide checks on other participants. Design objectives: One of our goals is to minimize the computational requirements of our scheme. For micro-payments, this means minimizing public-key cryptography in favor of faster private-key| and hash-function| based schemes. For example, as [27] point out: \as a rough guide, hash functions are about 100 times faster than RSA signature veri cation, and about 10,000 times faster then RSA signature generation: on a typical workstation, one can sign two messages per second, verify 200 signatures per second and compute 20,000 hash function values per second." (We remark that cryptographic hash-functions are in many of the above applications used solely as one-way functions which are one-way on their iterates { technically a weaker property then collision-resistance.) We also remark that private-key cryptography (for example, pseudo-random generators) is often even more e cient. Summarizing, one of our design objectives is to make use of e cient one-way functions (like MD5 [26]) and/or private-key cryptography and to minimize the use of digital signatures. Additionally, we wish to minimize the communication (both the number of rounds and the number of bits transmitted) per transaction, between all the parties, as well as computational requirements of our scheme and memory requirements for all the participants. We also wish to minimize potential fraud, which we elaborate upon further after reviewing previous proposals. To summarize, we wish to optimize the following parameters: { minimize the number of rounds of interaction per transaction between users and vendors and between the bank/broker and users and vendors; { minimize the number of total bits transmitted per transaction between users, vendors and the bank/broker; { minimize the computational demands needed per transaction for all the participants (i.e. minimizing the use of digital signatures in favor of lessexpensive means | see above); { minimize hardware requirements for all the participants (i.e. eliminate and/or minimize the use of large databases of revocation lists or other \per-transaction" lists; and/or the need of smart-cards; and/or expensive hardware for preprocessing); { minimize fraud (to be discussed in below after surveying other schemes.) Additionally, we discuss the issue of anonymity, which plays a role in some micropayment schemes, such as DigiCash [8]. Informally, the goal of anonymity is to minimize the user identi cation (both to the vendor and to the bank) when purchases are made. We remark that our schemes can be made anonymous as well. OUR RESULT: In the heart of our construction is an authenticated coinipping protocol. The protocol requires evaluation (and transmission) of only two hash functions per coinip after the initial setup. The authentication in our protocols guarantees (among other things) that the vendor can request a third party (such as bank/arbiter) to verify what the outcome of the coinip should be, and if the protocol is aborted in the middle, to prove (to arbiter/bank) what the outcome is and insist on the resumption from the right point in the protocol execution. We show how our protocols can be utilized to e ciently implement a coin ipping protocol of [31] where with some small probability (say, 1 200 ) the user pays a larger (say, 1$ dollar) amount. Notice that the expected cost per transaction in the above example is half a cent, while the expected overhead of handling the payment is now two hundred times smaller, thus allowing us to use (in the event of the \payment"-outcome coinip) an alternative, slow but secure payment mechanism. Our scheme is related to that of [24, 25], but with some important di erences, especially in the setup stage. We discuss these di erences and why they seem to be essential for the proof of security. In summary, the main technical contribution of this paper is the design of fair and authenticated coinipping protocol together with its proof of security. 2 Previous schemes and Techniques Credit-card setting and On-Line Schemes: In the current credit-card setting, every transaction is on-line, where whenever some customer wishes to pay a vendor, the Bank is always contacted. In particular, the Bank gets a request to transfer money from user's account to vendor's account. In order to do so, the bank rst veri es that the customer's account is in good standing (which requires a database lookup) and then gives to the vendor a validation number for the transaction. If Vendor's account is with a di erent Bank, this contact is also made at some point in time, di erent for di erent schemes. The cost per such transaction is about 10 cents, and hence is not nancially viable for tiny-cost transactions. Moreover, since the Bank must maintain 99.99% availability, even during peak tra c time (Anderson at. all. [1] mention that typically 1pm on the Saturday before Christmas is such a peak-time) this requires additional cost in order to maintain capability for additional throughput and backup systems. The main source of fraud in the current credit-card practice is from stolen [credit-card number, expiration-date] information, which can (and is) used to impersonate users. SET: Recently, Visa and Master-card developed a SET on-line analog of the credit-card setting, where digital signatures are used to authenticate all three parties (i.e. users, vendors and banks), so that an adversary who wire-taps all the communications, still can not impersonate users, since he can not forge signatures (for further details and features, see [30]). However, since signature generation and veri cation is required for all the parties, and since the Bank must be present on-line for every transaction, SET is clearly not suitable for tiny web-related transactions. NetBill: NetBill [6] is another on-line protocol (it has additional features like atomicity { i.e. customer pays only for messages that he gets; and anonymity via pseudonyms). It requires eight messages for each transaction and on-line communication with the intermediary NetBill server for each transaction. Electronic currency: DigiCash; NetCash. In electronic currency schemes, a user deposits some amount of money into the bank, that in return gives some digital data representing \Electronic currency" (also called an electronic \coin"). In its simplest form, electronic currency is an authenticated (by the bank) serial number. Of course, the danger with any such scheme is double-spending (i.e. where a user or someone else \spends" the same \coin" more the once). There are several ways to combat this: one is to insist on the on-line check (with the Bank) to verify if the coin have been already spent; the second is for the Bank to pay for each coin only once [27]; the third is to incorporate the identity of the user (who bought an electronic coin) into the coin itself, so that if it is spent twice, the known user will be prosecuted. A twist proposed by Chaum is to also have anonymity, where again Bank keeps track which \coins" have been spent, but where DigiCash [8] in case of double-spending reveals the identity of the User (for later prosecution { see also [9]). The issue, of course, is when to check for double-spending. One possibility (which is what Chaum's [8] current implementation does) is to do the check on-line, the other possibility is to check o -line, running the risk that the user will spend huge sums of money and then disappear, when discovering fraudulent activity is too late. Another \electronic currency" scheme is that of Medvinsky and Newman \NetCash" scheme [19]. The twist there is that they keep track only of the outstanding \tokens" (i.e. those that have been issued but have not been deposited), compared to Chaum's scheme where comparison with all tokens ever issued must be made. Never-theless, all these schemes must either be on-line, or stand the risk of \huge-spendingwith-quick-gateway" attack. NetCheque: University of Southern California NetCheque (TM) project [21] is another on-line scheme, where users issue checks for vendors using (as a certi cates of the validity of a check) a private-key cryptography (shared between a user and a bank.) This scheme is more e cient then public-key signatures, but requires registration of users at the banks and then subsequent clearance (i.e. checking by the bank of the validity of the private-key authentication) of checks by the bank to verify both correctness of the check and the availability of funds in user's account. Neuman and Medvinsky [21] argue that such on-line veri cation can be in some cases done o -line, but then the fraud (of bad checks) becomes as issue. Hardware-Based Schemes In hardware-based schemes, one assumes the existence of temper-resistant smart-cards, which contain private-keys, but such that this private-keys can not be extracted from the card without destroying its contents. This, in principle, allows to use faster private-key cryptographic means. One such example is the proposal of Stern and Vaudeny [29]. They offer a scheme where every smart card contains a master private key for MAC (i.e., private-key Message Authentication Codes). Every Vendor is given such a tamper-resistant smart card. Users buy from the bank "tokens" which are authenticated with banks private-key authentication mechanism. When a user wishes to make a payment, it gives the token that was provided by the bank to the Vendor's tamper-resistant devise which then veri es that it is a valid payment, and then gets paid from the bank. The idea is that the private key is known only by the bank, yet all vendors can verify that users provide correct private-key authentication tags, since they all have smart-cards with the banks private key. Again, clearance of this payments can be done either on-line (to prevent double-spending) or o -line (with black-listing double-spending users) as before. The drawback of this scheme is that if the unique bank's key on each of the vendors smart cards is recovered by an adversary, the security is lost. That is, the single private-key of the bank is distributed to every device, hence breaking even a single tamper-resistant device completely compromises the scheme. They suggest an extension which uses logarithmic (in the number of users) keys, and authenticating with all of them, but this, while it prevents the above threat makes the proposal less e cient. Various \electronic-wallet" hardware-based solutions are proposed by Mondex [18] and others, such as Yacobi e-war [32]. There are basically two di erent approaches. The rst approach is to keep the actual counter on the card { which increases/decreases during transactions, where the counter denotes the actual cash value (up to a certain limit). Since the counter is on the tamper-proof device it can not be increased. Of course, if one can arti cially increase the counter, this leads to money forgery. Another approach, is to keep digitally signed (by the bank) coins, where the only goal of the tamper-resistant device is to prevent double-spending [32] (where various methods (either on-line or o -line and/or probabilistic) are made to detect if some coin is spent twice and by what smartcard { the scheme requires revocation lists and if not done on-line has some over-spending threat.) Rivest and Shamir's Micro-Mint [27] propose to run (using huge o -line computations) schemes which nd collisions of (properly tuned, only somewhat hard to nd) collisions of collision-free hash-functions, to be used instead of signatures. This guarantees that forging is hard (basically using birthday-paradox type argument) but still duplication easy. They argue that duplication is not an issue since every coin will be paid only once (which requires storage of all the coins as well). Subscription schemes: Many large vendors, sell subscriptions for certain websites. Examples include $ 40 year-based subscription to on-line Wall-Street journal and $ 150 year-based subscription to Encyclopedia Britannica. The subscription payment is performed only once a year (by various means). Clearly, one of the drawbacks is that infrequent customers are not willing to pay a relatively high subscription cost. Moreover, the subscription-method is not suitable for \infrequently used" vendors of specialized information (like consumer reports information on how to purchase a new car). Besides, there is only so many subscriptions any user will sign-on, even if the cost of subscription is falling. In summary, while subscription-based approaches are and will be in use, an additional micro-payment approaches are needed as well. Another variant on the subscription scheme is a registration scheme where rst, customers register with the Vendor and prove its identity and then Vendors regularly charge them for transactions made. One such scheme is the \Chrg-http' protocol [7]. The drawback is the cost of registration, and, of subsequent unpaid charges. In light of the above, the development for tiny \per-use" payments schemes received considerable attention in the last two years. Below, we review various proposals. Coupon-based schemes DIGITAL's Milicent [11] is basically a private-key solution, where there is a \broker" which sells \vendor-speci c" coins. Vendorspeci c coin can only be authenticated by this vendor using vendor's private key (recall that the private-key authentication is much cheaper than public-key). Of course this solution requires \brokers" who must be trusted, and who should have agreements with vendors. Another coupon-based family of (similar to each other) solutions is Rivest and Shamir's PayWord, [27], Anderson's NetCard [1], Pederson's at. al. scheme [23], Jutla and Yung PayTree [22] and Hauser at. almicro-iKP [15]. The top-level idea of all this schemes is basically one of Lamport's [17] (also used for S/key [14]), and it is as follows: take a one-way permutation f (or a hash-function or a one-way function which is one-way on its iterates), pick a random input x, and iterate it some su ciently large number of times (say a 1000) (i.e. compute y = f(f(f : : : (f(x))))), then authenticate y (i.e. sign y and perhaps user's ID with banks public key signature). Now we have a chain of values of the form f (y); f (f (y)) : : : x with the property that given any pre x of this chain, it is hard to compute the next pre-image (since it involves inverting a one-way permutation) but easy to verify that this chain leads back to an authenticated y. The idea is for the bank to issue such (x; y; bank's signature(y)) triple to the user (for the appropriate fee), where every inverse is a single micro-payment. The user, when he wishes to make a payment to the Vendor, gives y (with appropriate banks public-key authentication of y { this is a one-time setup operation) to the Vendor, but then for each subsequent payment just gives the next inverse in the above chain. Jutla and Yung [22] generalize this chains to trees in a natural way. The drawback of all this schemes is double-spending, where to combat this the two approaches being taken are either to check on-line (which is expensive) or to black-list users (which is somewhat expensive too, and may not be su cient if user's identity can be easily changed/forged). Probabilistic Schemes The probabilistic schemes can be divided into two categories: probabilistic checking and probabilistic payment. We rst outline the probabilistic checking schemes and then describe the two previous probabilistic payment schemes. The rst two probabilistic checking protocols are probabilistic audit Agora protocol of Gabber and Silberschatz [10], and Jareski and Odlyzko probabilistic polling [16]. The idea there is basically as follows: the user gives (signed) promisory notes to the vendor, which the vendor later "cashes" to the bank, but when exactly this happens is done probabilistically, in order to limit the amount of over-spending. This approach combines (expensive) on-line approach of always verifying that the user has the money in his account (witch is communicationexpensive) and the o -line credit-based solution (which leads to over-spending/ black-listing solution.) Here the over-spending (by tuning the rate with which vendor talks to the bank to be a probabilistic function depending of the transaction size) can be limited. The drawback is similar to coupon-based schemes, namely the requirement that in case of detected over-spending the vendors/banks must "black-list" users (and, hence keep such databases) and to inform all vendors of bad users [16], as well as keeping, by each Vendor the list of revoked users [10]. The combination of software-based and hardware-based solutionwith probabilistic audit was suggested by Yacobi's e-war [32] project at Microsoft. In [32] Yacobi proposes smart-card id-based wallets that keep signed by the bank coins. Notice that the new coins can not be forged since only bank can sign, and the duplication is controlled using hardware where probabilistic checking is used to prevent double-spending. This solution requires both software and hardware, and can still take some amount of over-spending, though the amount can (as in the previous scheme) be made limited. The drawback is the need to black-list users/smart-cards and keep this databases around as above. The nal category of the probabilistic schemes is the so-called probabilistic payment category. Our scheme belongs in this category as well. The two other scheme in this category is Rivest's \lottery tickets as Micro-Cash" [24, 25] and Wheeler's \Transactions Using Bets" [31]. The [24] and [25] di er, and we review both. The idea of [24] scheme is for the bank to issue for each user a book of \lottery tickets" as follows: As in couponbased schemes, the bank, picks a random x, computes y = f(f(f : : : (f(x)))) for f a one-way permutation or a cryptographically-strong hash function, then authenticates y (i.e. signs y and perhaps user's ID with banks public key signature). Now we have a chain of values of the form f (y); f (f (y)) : : : x which is a \lottery book" of tickets (for each user and each vendor that the user wishes to talk to), where for each micro-payment transaction, the user pays with the next pre-image from this book (just like the coupon-based scheme.) The twist here is that the bank, later on announces one of the tickets from each book as a \winning ticket". If the user did not give this winning ticket to a Vendor (since it stopped early and did not use the entire book), it does not have to pay anything, if it did, it is responsible for the winning ticket (i.e. the bank will pay the amount to the Vendor upon Vendor's presentation of the winning ticket and will subtract it from user's account). It is important to note that the \lottery" is held after the book in question (say for this day) is no longer in use, otherwise the user could always avoid giving out the winning ticket. The advantage of the scheme is that if, say, half of the lottery tickets from a book have been used, then with probability one-half the user will not have to pay, thus making the amortized cost of transactions less costly. The drawback is the Bank's overhead of holding lotteries and having to check the results as well as the issue of timing (since the payments to the Vendor can be made only after the lottery is announced, at which time the user may not have su cient funds in its account.) In cite [25] (independently of our work) Rivest extends [24] suggestion using [31] approach and two chains, similar to our approach, but with some important di erences. We rst describe Wheeler's suggestion [31]: The second probabilistic micro-payment scheme is the protocol of Wheeler \Transactions Using Bets" [31], where he suggests, similar to our scheme to decide probabilistically whether the payment should be made. In particular, he suggests for the user and vendor to execute a standard coinipping protocol [2] (vendor commits a random number to the user, then user sends a guess of this number to the vendor, then vendor de-commits) in order for the user and vendor to decide if the user should pay. One of the aspects not addressed by the paper, is that the user should not be able to deny that the coinip protocol execution took place, and hence that he has to pay the agreed-upon amount in case of an unfavorable coinip. A natural way of dealing with this problem is to introduce digital signatures into the protocol, so that the vendor can prove (to a bank/arbiter) that this interaction took place. However the use of signatures makes the protocol ine cient. Another drawback of the [31] protocol is the danger that the protocol is aborted in the middle of the execution. Indeed this is a serious problem, since if the seller/user are allowed to abort the coinipping protocols and re-try again, the probabilities can be altered. This problem is indeed mentioned in the [31] paper, but no solution how to resolve this problem is given. In the current paper, we show how both problems can be resolved in an e cient manner. The most related (to our scheme) is the work of Rivest [25], which suggests for the user and vendor to exchange roots of two chains, and show inverses in order to de ne coinips. However, there are several crucial di erences in the two approaches, especially in the setup stage. We discuss speci c di erences in two schemes (and why they seem to be essential for the proof of security) after we preset our scheme.